The advent of microprocessors and microcomputers has provided electronic system designers greater functionality, higher speed and increased problem solving capability in digital computer systems. Microprocessors, running at clock speeds of 15 megahertz and above, are common tools of today's engineers. Chip designers are producing microprocessors and VLSI devices of orders of magnitude improvements in line width, gate count and clock speed. While microprocessor vendors are making these advances, test equipment vendors and test engineers struggle to devise new means to test these parts.
Microprocessor systems contain address, data and control lines, which depend upon feedback to operate. In doing so, the CPU sends out an address on address lines to memory, which outputs data on data lines which is fed back to the CPU. The CPU may write data to memory, using these address and data lines, controlled through specific logic signals on control lines. This information flow in both directions is the main difference between microprocessor systems versus conventional digital logic systems. Differences such as this have forced test equipment vendors to innovate new test tools with respect to microprocessor systems.
Emulator is the general name for one of these test tools which has been developed to access and control microprocessor based systems, for both hardware and software design, and for troubleshooting. Emulators for troubleshooting, as used in automatic testing, are commercially available in two main types: CPU type emulators and rom (read-only-memory) emulators. The use of a CPU type emulator, which is very powerful in its ability to control and exercise the circuitry system surrounding the CPU, is expensive because a different emulator is required for each different microprocessor type tested, to wit: a CPU type emulator is specific for each microprocessor under test.
On the other hand, rom emulators plug into the "bootstrap" or reset logical address space of the UUT system. These emulators are transparent to the UUT (unit-under-test) CPU, and appear as simply memory from which test routines, previously loaded into rom emulator memory (which is actually read/write memory), can be executed. The use of rom emulation is enjoying widespread acceptance commercially, because of low cost. As most rom devices found in microprocessor systems employ a JEDEC standard package type thereby allowing a standardization among rom plug types (the part which actually inserts into the rom socket) a rom emulator can easily interface existing connections of the UUT. Further, rom emulators are also software configurable, giving the capability to test many types of UUT CPUs with one rom emulator.
Testing at higher UUT CPU speeds is generally easier because most roms are slower than other system components and the UUT CPU is generally programmed to "wait" during rom accesses to allow the rom to "catch up" to the UUT CPU. This allows the read/write memory in the rom emulator a liberal amount of time to respond to UUT CPU instruction fetches. The effect of these programmed wait states increases the reliability of testing at high UUT CPU speeds and alleviates costs associated with testing high speed processors inherent in CPU type emulators.
However, there is one major drawback with the rom emulation technique. If there is a stuck, open or shorted address, data or control signal between the UUT CPU and the UUT rom, or the portion of the UUT CPU "kernel" which controls data access from the UUT rom location, the UUT CPU is unable to fetch the proper instruction sequence from the UUT rom.
CPU emulation does not suffer this limitation since the emulator CPU is located in the emulator, and is buffered by gates from any stuck or inoperative lines. A CPU type emulator contains its own ram, buffered and isolated from any UUT stuck or faulty address, data or control lines. In other words, a CPU type emulator's rom-to-CPU-address/data path is isolated and immune from stuck lines in the UUT. By its very construction a rom emulator is not so isolated and immune from stuck lines in the UUT.
To overcome the stuck kernel fault, when using the lower cost rom emulator, known methods have ranged from manual current pulser/tracer techniques to logic timing analyzers. But such methods have drawbacks as the problem presented by a stuck kernel fault is very difficult to pinpoint because the event sequence, spanning not more than a few microseconds, occurs only once each time the first instruction fetches are executed and fail.
FIG. 4 and the following explanation describe the typical sequence of events whenever the UUT CPU commences operation after initialize reset:
Time (1) address is put on address bus by CPU, PA1 Time (2) address latch enable is asserted by CPU, PA1 Time (3) address is latched by external address latches, PA1 Time (4) address arrives at rom sockets from address latches, PA1 Time (5) concurrent with 4 above, address high order bits arrive at memory decode circuit, PA1 Time (6) memory decoder decodes address high order bits and asserts its enable output, PA1 Time (7) enable output arrives at chip select input of rom socket, PA1 Time (8) read line is asserted at CPU, PA1 Time (9) read pulse arrives at rom socket and enables rom data outputs, PA1 Time (10) rom data is output from rom, PA1 Time (11) rom data pass through data buffers, PA1 Time (12) rom data outputs arrive at CPU whereby the address, data and control paths have been successfully exercised.
To diagnose faults during this sequence, one must simultaneously view all address lines, all data lines and certain control lines and the time at which the fault occurred must be captured, along with events succeeding it in time. To accomplish this, a means of triggering upon detection of a certain logic pattern is necessary; also the means of storing logic patterns at the various nodes is required. A logic analyzer is the usual tool for such diagnosis but is expensive and large, and usually requires manually clipping many test leads into various places in the kernel.
While a simpler logic analyzer approach can be taken which examines fewer lines at a time by moving fewer test leads around the different nodes and executing the UUT CPU reset to start the sequence numerous times. This technique is fraught with problems because the process of elimination is very subject to operator interpretation and is long and involved, requiring reiterations for collection and analysis of results.
Alternatively, a logic pulser and accompanying logic probe and current tracer can be effective in tracing stuck nodes in the kernel. But this technique requires a highly skilled technician who can accurately interpret results. Further, as it is slow and very time consuming, it is inadequate for high volume testing.
A solution is required for automatically analyzing failed nodes within the UUT rom-to-CPU-address/data path which is less costly and cumbersome than using a logic timing analyzer, which does not entail movement of many leads to different nodes numerous times, and which does not require error prone interpreted measurements.